1. Field of the Invention
The present invention relates to the field of computer software, and in particular to a method and apparatus for automatic accessibility assessment.
Sun, Sun Microsystems, the Sun logo, Solaris and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
2. Background Art
Computer programs make use of many input and output devices termed “interfaces.” However, some disabled users are unable to make use of all interfaces. Such users frequently rely on a set of interfaces termed “assistive technologies.” Thus, computer programs are tested for accessibility by testing whether they are compatible with assitive technologies. Current methods for accessibility testing require a human to manually and exhaustively test each aspect of a computer program for accessibility. This is expensive and does not prevent the possibility of human error. This problem can be better understood with a review of computer program accessibility.
Computer Program Interface
Computer programs execute a series of program statements to manipulate data. During execution, a computer program frequently provides data (output) to a user. Typical output devices include monitors, printers and speakers. During execution, a computer program also frequently receives data (input) from a user. Typical input devices include keyboards, mice, touch-sensitive monitors and microphones. A computer program interface is the means by which a user gives input to the computer program and receives output from the computer program.
Accessibility
Some users are unable to use certain computer program interfaces. For example, a blind user could not typically position a pointer on a monitor over a desired field using a mouse pointer since the only indication the pointer is in the correct position is visual. However, such limitations are overcome by taking accessibility into account when designing computer programs. For example, visual limitations are overcome by audio cues used to indicate the position of a mouse pointer in relation to objects on the screen. Additionally, a program may allow a user to operate the program using a keyboard as an input device exclusively. Thus, a blind user could use keystrokes to select a desired field. Additionally, some users with a disability make use of assitive technologies, such as screen readers, alternate keyboards and eye-following devices, to interface with computer programs.
It is necessary to test the accessibility of a computer program to determine whether a computer program is accessible to users with a disability. Prior art methods of accessibility testing include examining source code and exhaustively manually testing of computer programs.
Source Code
One method of ensuring computer program accessibility is to exhaustively examine the source code. A programmer selects an untested function of the computer program and determines whether the computer code provides a means for all types of limited users to access the function of the computer program. If computer code provides a means for all types of limited users to access the function of the computer program, the programmers selects another untested function until all functionality of the computer program is tested.
Whenever the programmer determines that the computer code does not provide a means for some types of limited users to access the function, the programmer notes the accessibility failure. Once the accessibility failures are known, either the computer program is modified to correct the failures or the failures are documented and left in the computer program. However, source code is not always available for testing. Additionally, human error is not prevented with this method. Thus, accessibility failures may remain undetected.
Exhaustive Manual Testing
Some human error is eliminated by another method of ensuring computer program accessibility. The computer program is executed and exhaustively manually tested as it executes. A technician begins execution of an assistive technology (e.g., a screen reader or magnifier). Then, the technician begins program execution and begins using the program. The technician selects untested functions of the computer program and determines whether the computer program provides access using the assistive technology. All accessibility failures are logged as they are encountered. By repeating this process with multiple assistive technologies, the technician determines whether the program provides a means for users with all types of disabilities to access the functions of the computer program.
Once the accessibility failures are known, either the computer program is modified to correct the failures or the failures are documented and left in the computer program. However, human error is not completely eliminated with this method. Thus, accessibility failures may remain undetected. Additionally, this method requires that the technician install the various assitive technologies before testing begins. Installing all assitive technologies for testing purposes is expensive and beyond the financial ability of some computer program creators. Additionally, human error in this process is high because the technician must be proficient in the use of all assistive technologies being tested.
HTML
In one prior art method, accessibility is automatically assessed for information stored in a format known as “Hypertext Markup Language (HTML)”. This file or script format allows the display of text, graphics and audio information, and provides links to other pages of information through “hyperlinks.” Hyperlinks are strings of characters in a particular format that specify the address of the desired page of information.
In particular, HTML is a system for marking documents to indicate how the document should be displayed, and how various documents should be linked together. HTML is a form of Standard Generalized Markup Language (SGML), defined by the International Standards Organization. HTML specifies the grammar and syntax of markup tags which are inserted into a data file to define how the data will be presented when read by a computer program known as a “web browser”. Conventional web browsers include Internet Explorer, Netscape Navigator, and others.
The data file, which is typically stored on a server, includes one or more web pages which are visited by users who have computers which may run different browsers. When a page is visited, HTML data output from the server is downloaded to the client computer. The client computer's browser processes the data to format a layout for the page so the page can be viewed by the user on a computer screen. Generally, HTML tags provide text formatting, hypertext links to other pages, and links to sound and picture elements. HTML tags also define input fields for interactive web pages.
An HTML application is made available to users on the web by storing the HTML file in a directory that is accessible to a server. Such a server is typically a web server which conforms to a web browser-supported protocol known as Hypertext Transfer Protocol (HTTP). Servers that conform to other protocols such as the File Transfer Protocol (FTP) or GOPHER may also be used, but do not support interactive HTML files.
HTTP defines a set of rules that servers and browsers follow when communicating with each other. Typically, the process begins when a user accesses an icon in an HTML page which is the anchor of a hyperlink, (for instance, by positioning a cursor on the icon and depressing a mouse button), or the user inputs a Uniform Resource Locator (URL) to his or her web browser, described below. A connection is then made to the server at the address and port number specified by the URL. Next, the browser sends a request to retrieve an object from the server, or to post data to an object on the server. The server sends a response to the browser including a status code and the response data. The connection between the browser and server is then closed.
HTML Document Accessibility
Since Hypertext Markup Language (HTML) is used to control how data in web pages is presented to a user, similar accessibility issues arise as with computer programs. For example, some web pages include visual or audio information some disabled users can not access. HTML provides a means to present alternative information when a disability makes one presentation inappropriate. For example, images are alternatively presented by textual descriptions. Then, a screen reader, an assistive technology, works in concert with a web browser to convert text into an audio format is used to present the textual descriptions to blind users. Automatic testers exist which scan the text and tags of HTML documents and log any accessibility problems. One such automatic tester is called “BOBBY” and is available for free on the world wide web.
Platform-Independent Programs
A platform-independent program (e.g., a Java program) is composed of a number of classes and interfaces. Unlike many programming languages, in which a program is compiled into machine-dependent, executable program code, platform-independent classes are compiled into machine independent bytecode class files. Each class contains code and data in a platform-independent format called the class file format. The computer system acting as the execution vehicle contains a program called a virtual machine, which is responsible for executing the code in platform-independent classes. The virtual machine provides a level of abstraction between the machine independence of the bytecode classes and the machine-dependent instruction set of the underlying computer hardware. Hence, a platform-independent language provides an example of a safe language.
A “class loader” within the virtual machine is responsible for loading the bytecode class files as needed, and either an interpreter executes the bytecodes directly, or a “just-in-time” (JIT) compiler transforms the bytecodes into machine code, so that they can be executed by the processor. FIG. 1 is a block diagram illustrating a sample platform-independent network environment comprising a client platform 102 coupled over a network 101 to a server 100 for the purpose of accessing platform-independent class files for execution of a platform-independent application or applet.
Sample Platform-Independent Network Application Environment
In FIG. 1, server 100 comprises development environment 104 for use in creating the class files for a given application. The development environment 104 provides a mechanism, such as an editor and an applet viewer, for generating class files and previewing applets. A set of core classes 103 comprise a library of classes that can be referenced by source files containing other/new classes. From development environment 104, one or more source files 105 are generated. Source files 105 contain the programmer readable class definitions, including data structures, method implementations and references to other classes. Source files 105 are provided to compiler 106, which compiles source files 105 into compiled “.class” files 107 that contain bytecodes executable by a virtual machine. Bytecode class files 107 are stored (e.g., in temporary or permanent storage) on server 100, and are available for download over network 101.
Client platform 102 contains a virtual machine 111 which, through the use of available native operating system (O/S) calls 112, is able to execute bytecode class files and execute native O/S calls when necessary during execution.
Platform-independent class files are often identified in applet tags within an HTML (hypertext markup language) document. A web server application 108 is executed on server 100 to respond to HTTP (hypertext transport protocol) requests containing URLs (universal resource locators) to HTML documents, also referred to as “web pages.” When a browser application executing on client platform 102 requests an HTML document, such as by forwarding URL 109 to web server 108, the browser automatically initiates the download of the class files 107 identified in the applet tag of the HTML document. Class files 107 are typically downloaded from the server and loaded into virtual machine 111 individually as needed.
It is typical for the classes of a platform-independent program to be loaded as late during the program's execution as possible; they are loaded on demand from the network (stored on a server), or from a local file system, when first referenced during the platform-independent program's execution. The virtual machine locates and loads each class file, parses the class file format, allocates memory for the class's various components, and links the class with other already loaded classes. This process makes the code in the class readily executable by the virtual machine.